1. Field of the Invention
The present invention relates to a method, system, and program for making objects available for access to a client over a network.
2. Description of the Related Art
The Java** Remote Method Invocation (RMI) system, developed by Sun Microsystems, Inc., provides a framework in which objects on separate computers may communicate over a network. RMI is a Remote Procedure Call (RPC) mechanism that may be implemented using more than a single transport protocol. In the Java RMI framework, an object on a server is represented on a client system by a stub or proxy object. Applications running on the clients can call a local method on the proxy object that causes the corresponding method on the remote object to be invoked. When a proxy method is invoked, the proxy object communicates with the RMI runtime system on the server side and the proxy object communicates parameters to the remote object. The JVM including the remote object may lie on a remote system or the same system including the proxy object. The proxy object then receives the result of the method invocation and returns the value (if any) to the caller.
In distributed computing environments, services and clients running in different machines or address spaces may utilize RMI to allow clients to access remote services in another address space, such as a remote server. When accessing a remote service using RMI, the client may receive objects from the service (the service might also receive objects from the client), yet not have loaded the classes needed to manipulate the received objects. For instance, when the client receives return values (or exceptions), the client needs the class definitions for such received objects to use the data received from the remote server. The RMI specification provides for dynamic class loading (also known as network class loading or remote class loading) of the class definitions for the objects received from remote services that are not locally available at the client. This includes the dynamic downloading of remote classes needed by the client to use any object passed in RMI calls for which the class is not locally available. Once all necessary classes are downloaded from the remote address space, the client can then execute or otherwise manipulate objects returned by the remote service in response to the RMI call.
In the prior art, the client will download the classes in a file conforming to the Java Archive Format (JAR) file format or download the classes individually if they are not packaged in a JAR file, which is a file format based on the ZIP file format and is used to aggregate many files. JAR files are used to encapsulate multiple files into a single file that contain class files and other resources associated with a Java applet, application or component. The remote server would provide the client the classes needed for dynamic downloading in one or more JAR files.
The client invokes a class loader to download the class files the client needs, which may be packaged in JAR files, from an Hypertext Transfer Protocol (HTTP) server. A codebase is the location encoded as a URL from where the class loader downloads the needed class files. The codebase URL is associated with a serialized stream of bytes that indicates from where the class represented by those bytes can be loaded. Codebases are required for dynamic class loading to work. The process by which the client may download the bytecodes of classes to run programs not previously installed on the client is referred to as dynamic class loading. The process may begin with the client requesting a reference to a named remote object. Additionally, the reference may be provided to the client as the return value of a remote call or as a parameter of a callback method. An RMI registry returns a proxy to the remote object, also known as a stub or proxy object, to the requesting client. The proxy object may also be retrieved using mechanisms other than the RMI registry. In certain situations, if the client can locate the class definition for the stub instance in the client JVM CLASSPATH, then the client will load the class locally. If the client cannot load the class locally, then the client will request the class definition using the codebase, which is a URL annotated to the serialized bytestream representing the stub instance so that the client may dynamically download the class files, which may be included in a JAR file, that includes the classes the client needs to invoke remote methods on the remote object. Additionally, objects other than proxy objects might be received by a client and require class files that the client must dynamically download.
One complication in the above process is that the administrator must take certain actions to ensure that a URL is identified for each JAR that might need to be downloaded. In the prior art, this often requires the server administrator to explicitly specify the codebase (e.g., by setting a system property). This is often referred to as setting the codebase. The administrator may also register the remote object with an RMI registry. The codebase is annotated to the bytestream of the remote object when it is serialized for transport. This process to make a JAR file available to a client class loader using an HTTP server is the source of many problems in implementing a network system that makes use of RMI.
Accordingly, there is a need in the art to provide improved techniques for making programs and classes available to clients in a network.